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ABSTRACT 


The requirements development process for the Advanced Engineering Environment (AEE) is presented. This 
environment has been developed to allow NASA to perform independent analysis and design of space 
transportation architectures and technologies. Given the highly collaborative and distributed nature of AEE, 
a variety of organizations are involved in the development, operations and management of the system. 
Furthermore, there are additional organizations involved representing external customers and stakeholders. 
Thorough coordination and effective communication is essential to translate desired expectations of the 
system into requirements. Functional, verifiable requirements for this (and indeed any) system are necessary 
to fulfill several roles. Requirements serve as a contractual tool, configuration management tool, and as an 
engineering tool, sometimes simultaneously. The role of requirements as an engineering tool is particularly 
important because a stable set of requirements for a system provides a common framework of system scope 
and characterization among team members. Furthermore, the requirements provide the basis for checking 
completion of system elements and form the basis for system verification. Requirements are at the core of 
systems engineering. The AEE Project has undertaken a thorough process to translate the desires and 
expectations of external customers and stakeholders into functional system-level requirements that are 
captured with sufficient rigor to allow development planning, resource allocation and system-level design, 
development, implementation and verification. These requirements are maintained in an integrated, 
relational database that provides traceability to governing Program requirements and also to verification 
methods and subsystem-level requirements. 


INTRODUCTION 

Design and engineering analysis of complex and 
costly systems often requires analysis tools and 
expertise from around the country. Gathering all the 
necessary individuals and resources into a central 
location can be expensive, time consuming, and 
inconvenient for the individuals involved. One way 
to make the engineering process more streamlined is 
to develop the capability for engineers to share data 
and collaborate in a distributed environment. The 
Advanced Engineering Environment (AEE) is both a 
collaborative and distributed environment involving 
six NASA centers including Ames Research Center 
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(ARC), Glenn Research Center (GRC), Johnson 
Space Center (JSC), Kennedy Space Center (KSC), 
Langley Research Center (LaRC), and Marshall 
Space Flight Center (MSFC). The AEE allows 
NASA to analyze space transportation architectures 
and technologies in support of the Next Generation 
Launch Technology (NGLT) Program and related 
activities. 

The AEE is configured to facilitate data management, 
automated tool/process integration and execution, 
and data presentation. PTC's Windchill, Phoenix 
Integration's ModelCenter and an XML-based data 
capture and transfer protocol make up the AEE 
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framework. The user interface, data management, 
tool execution and data presentation capabilities are 
directly and securely accessible from the World Wide 
Web. 

The integration of tools within AEE uses Phoenix 
Integration’s ModelCenter and Analysis Server 
software applications. Analysis Server essentially 
"serves up" discipline tool analysis capability. 
ModelCenter acts as the Graphical User Interface 
(GUI) that allows a particular user to control the 
tool(s) served by the Analysis Server(s). 

The Windchill Product Data Management (PDM) 
capability provides process/workflow management, 
web based access to project data stored within an 
Oracle database, and configuration management 
capabilities. 

Reporting and visualization capabilities for various 
tools in the AEE environment are provided via a web 
interface. These range from detail to summary 
reporting and vary from tool to tool. 

AEE Project formulation was initiated under the 
Intelligent Synthesis Environment (ISE) Program in 

1999. Within the ISE Program, the project was 
organized as the Reusable Space Transportation 
System (RSTS) Large Scale Application (LSA). The 
ISE Program formed a partnership with the 2 nd 
Generation RLV Program in 2000 - focused on 
acceleration of the RSTS activities. The ISE 
Program was terminated at the end of FY01 and 
thereafter the RSTS activities were retained and 
supported by the 2 nd Generation RLV Program under 
the AEE Project. The AEE design was initiated in 

2000, development activity was initiated in 2001, and 
utilization was initiated in 2002. The AEE Project 
was reassigned under the MSFC Systems 
Management Office (SMO) in early 2003 to provide 
support for the engineering/analysis requirements of 
multiple programs such as Next Generation Launch 
Technology (NGLT). 

THE REQUIREMENTS 
DEVELOPMENT PROCESS 

Given the highly collaborative nature of the AEE 
Project, many different organizations are involved in 
the development, operations and management of the 
system itself. Furthermore, there are yet more 
organizations involved that represent external 
customers and stakeholders. Thorough coordination 
and effective communication is essential to translate 
desired expectations of the system into requirements. 
Functional, verifiable requirements for this (and 


indeed any) system are necessary to fulfill several 
roles. Requirements serve as a contractual tool, 
configuration management tool, and as an 
engineering tool, sometimes simultaneously. The 
role of requirements as an engineering tool is 
particularly important because a stable set of 
requirements for a system provides a common 
framework of system scope and characterization 
among team members. Furthermore, the 
requirements provide the basis for checking 
completion of system elements and forms the basis 
for system verification. Requirements are at the core 
of systems engineering. 

The AEE Project has undertaken a thorough process 
to translate the desires and expectations of external 
customers and stakeholders into functional system- 
level requirements that are captured with sufficient 
rigor to allow development planning, resource 
allocation and system-level design, development, 
implementation and verification. These requirements 
are maintained in an integrated requirements/decision 
database (IRDDB) using the CORE systems 
engineering tool that provides traceability back up to 
higher-level Program requirements and also down to 
verification methods and subsystem-level 
requirements. The IRDDB also provides a functional 
analysis capability and framework that enables the 
refinement of the requirements based on use-case 
oriented functional flows. 

The overall requirements development process for 
AEE is based upon accepted standards and guidelines 
that have been appropriately tailored to this project. 
The standards and guidelines being used include: 

• NASA Policy Guidance (NPG) 7120.5B, 
NASA Program and Project Management 
Processes and Requirements 

• NPG 87 15.3, NASA Safety Manual 

• Institute of Electrical and Electronics 
Engineers (IEEE) 1220, IEEE Standard for 
Application and Management of the 
Systems Engineering Process 

• MSFC-HDBK-3173, Project Management 
and System Engineering Handbook 

• American National Standards Institute 
(ANSI)/EIA-632, EIA Standard, Processes 
for Engineering a System 

• NASA-SP-6105, NASA Systems 
Engineering Handbook 

• MIL-STD-961D, Department of Defense 
Standard Practice for Defense Specifications 
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Furthermore, many of the systems engineers 
supporting these activities for the AEE Project are 
members of the International Council on Systems 
Engineering (INCOSE) and have attended various 
courses and seminars offered by INCOSE on 
requirements development and systems engineering. 

Some details of the requirements development 
process for AEE are presented next. 

IDENTIFYING CUSTOMER 
EXPECTATIONS 

The term “customer” here is used synonymously with 
the term “stakeholder”. In this context, the term 
customer or stakeholder refers to any person or 
organization that has a vested interest in the 
development and performance of the AEE system. 

Customer (i.e., stakeholder, user) expectations for the 
products and deliverables associated with AEE are 
identified and flowed down from stakeholder 
requirements and plans. Face-to-face meetings and 
workshops are held with stakeholders, in lieu of 
formal documentation, to determine expectations for 
AEE. Explicit expectations that are represented as 
quantifiable requirements and performance 
parameters are captured in the AEE IRDDB so that 
traceability to derived AEE system requirements can 
be established and maintained. 

DEFINING OPERATIONAL 
SCENARIOS 

Operational scenarios that define the range of use of 
the AEE system are identified and developed based 
on discussions with developers and users. Upon 
identification, these scenarios are used primarily to 
identify system baseline functionality which will lays 
the foundation for functional analysis activities (e.g., 
functional modeling). Functional analysis then 
decomposes top-level AEE system functionality 
relative to its required behavior in performing 
analyses in support of stakeholder Program 
milestones and other identified operational/mission 
objectives. Scenarios were refined using Functional 
Flow Block Diagram (FFBD) techniques. Top-level 
scenarios, captured as discrete events (functions), 
will be further decomposed down to leaf-level system 
functions that reflect manageable threads of behavior 
(stimulus/response threads) are then be modeled and 
conveyed in detail using Enhanced FFBD (EFFBD) 
techniques. The NASA Systems Engineering 
Handbook, as well as most tutorials on disciplined 
Systems Engineering, provides further information 


regarding the application of functional analysis 
techniques to define required system functionality. 
Defining detailed AEE system functionality as a 
logical flowdown from the AEE mission life cycle 
ensures direct traceability between stakeholder 
operational needs and derived system functional 
requirements. 

FUNCTIONAL ANALYSIS 

AEE Systems Engineering performs functional 
analysis in coordination with the developers and 
users of the system. This is done in order to 
completely define the AEE system’s functional 
architecture. This definition of the system’s 
functional architecture is then used to structure and 
refine the system-level requirements. It should be 
noted that the functional requirements baseline will 
have been derived and flowed down from appropriate 
AEE operational scenarios, thus keeping stakeholder 
operational source requirements at the top of the 
functional hierarchy and maintaining traceability to 
these source requirements. Each function comprising 
the functional requirements baseline will be further 
decomposed to identify leaf-level system 
functionality if/as necessary. The functional 
requirements baseline and subsequently identified 
system-level requirements will be represented in 
FFBD notation as discrete events with associated 
quantifiable performance criteria. Early AEE Test 
and Verification involvement in this requirements 
analysis activity is necessary to ensure that AEE 
functional/performance requirements are verifiable. 

Detailed functions identified as the result of 
functional analysis will then provide the basis for 
development of lower level Hardware and Computer 
Software Configuration Item (HWCI, CSCI) 
requirements. Again, traceability is maintained from 
the operational scenario level (FFBD), through the 
system functional requirements level (FFBD), and on 
to the allocated functional requirements level 
(EFFBD). 

A Systems Engineering tool, CORE, is utilized to 
perform the functional analysis. This tool provides 
graphical functional modeling techniques (i.e., 

FFBD, EFFBD) and the capability to perform a 
complete functional analysis that produces an 
integrated and accurate functional hierarchy; it also 
maintains continuity from the AEE system root 
function and the functional context diagram through 
functional decomposition. The SE tool also provides 
for the identification of discrete performance 
parameters that will be linked to the associated 
functionality. Resulting AEE system and component 
functional requirements with associated performance 
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then directly populate, via database query, the AEE 
System Requirements Document (SRD). 

DEFINING SYSTEM BOUNDARIES 
AND INTERFACES 

In general, any external influence to the functionality 
of the AEE system must be identified, captured, 
managed, and controlled ensure the correct format 
and integrity of all data received from, and 
transmitted to, external systems. The system of 
interest for this Project is the AEE system, including 
its required interfaces, software, and hardware 
components. The AEE system’s primary data 
interfaces will be with the various sources of data for 
the architectures and technologies to be analyzed and 
assessed. Other systems external to the AEE that 
must be considered, particularly in support of 
detailed functional modeling, are those that provide 
direct and indirect stimulus/response functionality 
and observables (inputs and outputs). These external 
systems are currently minimally defined as the 
operator/user, sources of architecture and technology 
data to be analyzed, and external environment (i.e. 
other influencing events that impact system 
functionality). As the requirements analysis activity 
progresses, these external systems may be 
supplemented by additional identified systems with 
which the AEE must interoperate. It is also 
anticipated that the architecture and technology data 
sources will be further decomposed to identify each 
explicit source. 

Functional and physical AEE system interfaces are 
defined in quantitative terms to ensure that they can 
be verified during system test activities. AEE Test 
and Verification participation in this phase of the 
AEE SE process is therefore necessary. Functional 
interfaces are established by considering the system 
of interest, the AEE, within its operational context, 
and external systems with which the AEE must 
functionally interoperate. Development and 
assessment of the AEE system’s physical architecture 
will result in identification and definition of required 
AEE physical interfaces to which the functional 
interface requirements can be allocated. Subsequent 
functional analysis and synthesis activities will 
develop the detailed functional observables 
(inputs/outputs) that will be allocated to the 
applicable physical interface. The IRDDB is used to 
capture resulting system boundary and interface 
requirements. 

DEFINING FUNCTIONAL 
REQUIREMENTS 


AEE system-level functions are defined through 
decomposition of the AEE system’s root functions. 
Decomposition of the AEE system’s root function is 
based upon operational scenarios identified through 
discussions with developers and users. This 
approach ensures that required AEE system 
functionality is derived directly from operational 
needs, thus ensuring that system functionality meets 
stakeholder needs. It should be noted here that AEE 
System functional requirements will be derived from 
the stakeholder operational requirements rather than 
simply identifying analysis tools and/or their 
functionality, either currently in use or contemplated 
for future use. The identification of an analysis tool 
should represent a physical design/implementation 
solution that is captured at lower levels of 
requirements specifications (Level IV) and to which 
system-level functional requirements are allocated. 
The functional requirements resulting from this 
activity populate section 3.2.1, Performance 
Characteristics, of the AEE SRD. The IRDDB 
Function element class will be used to capture and 
decompose all derived system functional 
requirements. AEE system-level functions will be 
further decomposed and defined as a result of the 
functional analysis activities, including functional 
modeling. 

DEFINING PERFORMANCE 
REQUIREMENTS 

A complete functional requirement consists of two 
primary aspects: 1) The basic capability (function) 
that is required, and 2) the quantified performance 
criteria of the required capability. Multiple 
performance criteria may be associated with a single 
function or capability. Each performance criteria is 
maintained in the IRDDB, and linked to the 
corresponding function, using the Performance Index 
element class and the “exhibits/exhibited by” 
relation. Performance criteria will be defined for 
each AEE function and interface item to describe 
how well functional requirements must be performed. 
It is possible that system performance could be 
conveyed through non functional requirements. It is 
also recognized that when a function, or other 
requirement is defined which has one aspect of 
performance, that performance criteria is more 
efficiently stated as part of the basic requirement 
rather than designating another IRDDB element to 
capture the performance criteria. Performance 
criteria will be determined in much the same way that 
corresponding functions are identified and defined as 
described in the preceding section. Detailed 
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functional modeling, primarily through the 
development of stimulus/response threads of 
behavior provide the primary framework within 
which to develop performance requirements. Other 
detailed performance criteria will flow down from 
stakeholder-stated needs and requirements regarding 
system performance metrics. These performance 
criteria will be derived from ongoing efforts by 
Systems Engineering to identify performance metrics 
that are critical to AEE stakeholders. AEE System 
performance criteria will be linked to the appropriate 
stakeholder source requirements. Early AEE Test 
and Verification involvement in this requirements 
analysis activity is necessary to ensure that AEE 
system performance requirements are verifiable. 

DEFINING PHYSICAL 
CHARACTERISTICS AND OTHER 
QUALITY FACTORS 

AEE physical characteristics (e.g., size, weight, 
finish) and other quality factors (e.g., reliability, 
maintainability) will be derived from stakeholder 
requirements and analysis plans. Since the AEE is a 
software support system rather than a flight system, it 
is anticipated that minimal physical and other quality 
factor requirements will be levied. Those physical 
requirements that are applicable will probably be 
associated with system availability and the user 
interface. Human factors requirements will therefore 
also drive AEE physical requirements. Early AEE 
Test and Verification involvement in this 
requirements analysis activity is necessary to ensure 
that AEE system physical and other quality factors 
requirements and environmental requirements are 
verifiable. The AEE SRD format, based on MIL- 
STD-961D and its associated Data Item Descriptions 
(DIDs), was used as a checklist to ensure that all 
potential physical and other quality factors have been 
considered for applicability to AEE and addressed as 
necessary. 

DEFINING HUMAN FACTORS 

To ensure that the requirements developed for the 
AEE system are user-centered and lead to a system 
that is usable, supplemental Human Factors and User 
Interface (UI) Usability evaluation activities will be 
performed by Systems Engineering. These activities 
are described in detail in the AEE UI Usability 
Evaluation Management Plan. The objective is to 
define the approach to supporting the development 
and implementation of the AEE User Interface 
Usability Evaluation Facility in the Army-NASA 
Virtual Innovations Laboratory (ANVIL). Results of 
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these efforts will be used to further support the 
definition of AEE non-functional requirements as 
well as functional and performance requirements. 

THE SYSTEM REQUIREMENTS 
REVIEW (SRR) 


Once the initial set of AEE system-level requirements 
was drafted based on this overall process, a System 
Requirements Review (SRR) was initiated to 
examine the requirements. The overall intent of an 
SRR is to confirm that the system-level requirements 
are sufficient to meet AEE Management’s overall 
intent for the Project. 

The specific objectives of the AEE SRR are to: 

1. Confirm that the system-level requirements are 
sufficient to meet program/project/mission 
objectives. (Based on SRR guidance in the NASA 
Systems Engineering Handbook and MSFC-HDBK- 
3173) 

2. Evaluate the system-level requirements to ensure 
they represent identified customer and stakeholder 
expectations and project, enterprise, and external 
constraints. (Based on SRR guidance in IEEE 1220 
and ANSI/EIA-632) 

3. Assess the system-level requirements to ensure 
that they are achievable within project resources. 
(Based on guidance in NPG 7120.5B) 

4. Assess the system-level requirements for any 
conflicts and identify alternative functional and 
performance requirements where necessary. (Based 
on SRR guidance in IEEE 1220) 

5. Conduct a preliminary Hazard Analysis. (Based 
on guidance in NPG 87 15.3) 

An SRR Kick-Off meeting was conducted to 
introduce the participants to the draft AEE SRD. 

This consisted of a summary-level review of the SRD 
contents, explanation of rationale for what is in the 
SRD and why, origination of the requirements, 
addressing questions, etc. Additionally, the Kick-Off 
meeting reviewed the guidelines for the generation of 
SRD Comment Forms and the disposition process. 
The Kick-Off Meeting marked the start of the SRR 
Review Period. The SRR Review Period consisted of 
the SRR Participants reviewing the AEE SRD in 
accordance with the objectives in this SRR Plan and 
generating SRD Comment Forms as appropriate. All 
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Comment Forms generated during the review period 
were forwarded to the AEE Project Management 
Team (PMT), who jointly screened the forms and 
determined the disposition (accept the comment for 
incorporation into the SR D, disapprove the comment, 
request clarification from the originator). This 
dispositioning process occurred over a series of 
teleconferences. This dispositioning process also 
generated a series of action items with the overall 
intent of refining the draft SRD. All SRD Comment 
Forms approved for incorporation, along with work 
completed and inputs obtained during the process of 
resolving the action items, was used to generate a 
final draft AEE SRD. This final draft was then used 
as the basis to establish the initial system-level 
requirements baseline for AEE. 

The overall value of this process to the AEE Project 
was the generation of a stable, traceable and 
verifiable set of system-level requirements that 
helped establish an overall technical and management 
consensus on the design and development path of the 
system. This process also helped facilitate the 
discussion, negotiation and prioritization of new 
requirements. 


OBSERVATIONS, LESSONS 
LEARNED AND CONCLUSIONS 

The collaborative and distributed nature of AEE 
makes it a powerful system to conduct and support 
design and analysis activities. The very nature of this 
collaboration and distribution also means that there 
are a variety of organizations involved in the 
development, operations and management of the 
system. The fact that multiple organizations involved 
means that extra resources and effort are required to 
ensure effective coordination and communication to 
achieve consensus on the requirements. A high 
degree of collaboration is good but it usually means 
there are a larger number of external dependencies on 
the system that require management attention at 
multiple locations. 

It takes alot of engineering analysis to perform the 
translation of customer and stakeholder desires into 
rigorously written functional requirements that are 
both verifiable and traceable. Systems engineering 
resources should be adequately scoped to ensure 
success on these activities, particularly for distributed 
and collaborative systems requiring more 
coordination with different organizations than similar 
development activities for systems that are less 
distributed and collaborative. 


Security requirements can be difficult to define for 
collaborative systems due to differing computer 
security / firewall policies at various distributed 
facilities, etc. A balance needs to be struck between 
maximizing collaborative capabilities while 
implementing the right levels of security. 

A common definition of terms among different 
organizations may sound like a small thing, but it is 
essential in order to achieve requirements, design and 
implementation consensus for a highly collaborative 
system. 

Defining the boundaries of any system is a key to 
defining the requirements. A common understanding 
of boundaries, including physical, functional, and 
responsibility-oriented, is more difficult on a 
distributed and collaborative system where a variety 
of organizations are involved. Different 
organizations, whose local policies and procedures 
may not all be consistent, can view responsibilities 
and boundaries in different ways. Developing a 
common understanding across all the participating 
organizations is very important in refining and 
establishing consensus on the requirements. This is 
particularly true for Internet-based systems that house 
servers and other hardware (and software) 
components and networks, etc., in different facilities 
governed by different management organizations. A 
common understanding of the physical architecture 
and the associated external (and internal) boundaries 
has a direct impact on the ability to adequately define 
interface requirements, for example. 

Alignment of requirements priorities is crucial for 
resource management, particularly where a variety of 
customer and stakeholder organizations are involved, 
who can have competing requirements priorities 
between themselves 

Advanced electronic meeting / coordination methods 
are valuable but don’t entirely take the place of face- 
to-face sessions at the working level. However, 
WebEx has turned out to be a very effective tool. 
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